arm64: Fix eosimpact-en image build failures #202
Conversation
starnight
force-pushed
the
list-more-aarh64-unsupported-apps-eos6.0
branch
2 times, most recently
from
67355ad to
4777ae5
Compare
Here lists more Flathub apps gathered from endless-image-config, but they do not support aarch64. This avoids install the apps on arm64 images. https://app.asana.com/1/1203676861188277/project/1211949321657103/task/1212671431325376
starnight
force-pushed
the
list-more-aarh64-unsupported-apps-eos6.0
branch
5 times, most recently
from
5c838b1 to
4bb09c1
Compare
starnight
changed the title
starnight
force-pushed
the
list-more-aarh64-unsupported-apps-eos6.0
branch
from
ed8689a to
905f30e
Compare
stages/eib_image
Outdated
| *) | ||
| # On ARM disable 64bit ext4 option | ||
| ext4_opts="dir_index,^huge_file,^64bit" | ||
| ext4_opts="dir_index,^huge_file" |
There was a problem hiding this comment.
I'm curious whether these options are needed at all now that they are the same between architectures.
You could verify this with git blame etc. but from memory: the reason we set the filesystem parameters at all is that at one point we created the image in multiple steps: first a minimal image containing the files used during boot (as determined by systemd-readahead); then we grew the image to its final size and copied the rest of the data. This was so that all files needed during boot would be physically close together, improving boot performance from DVD. https://blogs.gnome.org/wjjt/2017/12/06/everything-in-its-right-place/
There was a problem hiding this comment.
I'm wrong. This was originally introduced specifically to disable 64bit on 32-bit ARM: commit df44a3a
So you could fully revert that patch and specify ext4_opts in one place, rather than having this architecture-specific branching but using the same value on both branches.
There was a problem hiding this comment.
I was curious why we disable huge_file. It dates back to @dsd's "Initial commit of new image builder" in 2014, without explanation. https://github.com/endlessm/endless-image-config/commit/0e559242743a0d410f185dd7ac88bdd07c6f54e5#diff-ca62344851add9817b4c7f08bc9a836553278fd22f36aff6c7137e251b09c70dR80
There was a problem hiding this comment.
I'm not sure either! This was copying the way that OLPC images were set up from ~2009, but there isn't full history available there.
It was likely either to make the filesystem behave more efficiently for storage devices that are way smaller than 2TB, or for bootloader compatibility.
I recommend dropping this now.
There was a problem hiding this comment.
Fixed the commits in the new commits.
This reverts commit df44a3a. EOS builds image with offline content. So, the image might be larger than 100 GB. Enable ext4's 64bit option to support larger storage. Besides, EOS builds the arm64 images, not 32 bits arm anymore. Then, both amd64 and arm64 platorms can share the same ext4 options. https://app.asana.com/1/1203676861188277/project/1211949321657103/task/1212760656967809
Use ext4's default huge_file configuration, instead of force disable it. This reduces complexity. https://app.asana.com/1/1203676861188277/project/1211949321657103/task/1212760656967809
starnight
force-pushed
the
list-more-aarh64-unsupported-apps-eos6.0
branch
from
905f30e to
443e65d
Compare
https://app.asana.com/1/1203676861188277/project/1211949321657103/task/1212671431325376
https://app.asana.com/1/1203676861188277/project/1211949321657103/task/1212760656967809